Enhancements: Added documentation for new functionalities. #21
Conversation
* Added openAPI specification and Sequence diagrams for Get CrmOrgUsers API. * Added Postman Collection for Search CrmOrgUser.
Accounts feed docs
Get CrmActionSuggestions docs
Added accounts feed api in postman collection
Updated create note sequence diagram
Added openAPI specifications of disconnect user API
Architecture diagram
…on-guide Added Document on how to configure Salesforce Account
Added open ai in architecture diagram
WalkthroughThis pull request introduces significant changes to the SalesSparrow application, focusing on enhancing API specifications, improving error handling, and refining sequence diagrams. It also adds a Salesforce configuration guide and an architecture diagram for better understanding of the system. Changes
TipsChat with CodeRabbit Bot (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 18
Files ignored due to filter (14)
- architectureDiagram.png
- openApiSpecifications/AccountNotes.yaml
- openApiSpecifications/AccountTasks.yaml
- openApiSpecifications/Accounts.yaml
- openApiSpecifications/Auth/Disconnect.yaml
- openApiSpecifications/Auth/Logout.yaml
- openApiSpecifications/Auth/Salesforce.yaml
- openApiSpecifications/Components.yaml
- openApiSpecifications/CrmOrganizationUser.yaml
- openApiSpecifications/Suggestions.yaml
- openApiSpecifications/Users.yaml
- openapiSpecifications/Components.yaml
- postman/AI-Sales-Sparrow-local.postman_environment.json
- postman/AI-Sales-Sparrow.postman_collection.json
Files selected for processing (20)
- README.md (1 hunks)
- openApiSpecifications/index.md (1 hunks)
- salesforceConfigurationGuide.md (1 hunks)
- sequenceDiagrams/AccountNotes/CreateNote.mermaid (4 hunks)
- sequenceDiagrams/AccountNotes/DeleteNote.mermaid (1 hunks)
- sequenceDiagrams/AccountNotes/GetNoteById.mermaid (2 hunks)
- sequenceDiagrams/AccountNotes/GetNotesList.mermaid (1 hunks)
- sequenceDiagrams/AccountTasks/CreateTask.mermaid (1 hunks)
- sequenceDiagrams/AccountTasks/DeleteTask.mermaid (1 hunks)
- sequenceDiagrams/AccountTasks/GetTasksList.mermaid (1 hunks)
- sequenceDiagrams/Accounts/GetAccounts.mermaid (2 hunks)
- sequenceDiagrams/Accounts/GetAccountsFeed.mermaid (1 hunks)
- sequenceDiagrams/Auth/Disconnect.mermaid (1 hunks)
- sequenceDiagrams/Auth/RedirectUrl.mermaid (1 hunks)
- sequenceDiagrams/Common/OAuthRequestHelper.mermaid (7 hunks)
- sequenceDiagrams/Common/UserAuthIntercepter.mermaid (3 hunks)
- sequenceDiagrams/CrmOrganizationUser/GetCrmOrganizationUsers.mermaid (1 hunks)
- sequenceDiagrams/Suggestions/GetCrmActionSuggestions.mermaid (1 hunks)
- sequenceDiagrams/User/GetCurrentUser.mermaid (1 hunks)
- sequenceDiagrams/index.md (1 hunks)
Files skipped from review due to trivial changes (5)
- README.md
- openApiSpecifications/index.md
- sequenceDiagrams/AccountNotes/GetNoteById.mermaid
- sequenceDiagrams/Auth/RedirectUrl.mermaid
- sequenceDiagrams/index.md
Additional comments (Suppressed): 27
sequenceDiagrams/AccountNotes/CreateNote.mermaid (6)
1-6: The participant name has been changed from 'SalesSparrow App' to 'SalesSparrow Client'. Ensure that this change is consistent across all sequence diagrams and documentation.
14-18: The request path has been updated from
{api_base_url}/api/v1/accounts/{account_id}/noteto{api_base_url}/v1/accounts/{account_id}/note. Also, theaccount_idhas been moved from query params to path params. Make sure all client-side calls are updated accordingly.28-30: A new validation check has been added for the text character length. This is a good practice to prevent excessively long notes.
34-50: The variable name has been changed from
current_usertocurrentUser. Ensure that this change is reflected in all relevant parts of the codebase.54-58: The error response code has been specified as 500 for any errors from Salesforce. This is a good practice for better error handling.
71-72: The response format has been updated to include the note_id in the body instead of just returning it as a string. This provides a more structured response format.
sequenceDiagrams/AccountNotes/GetNotesList.mermaid (5)
19-20: The error message returned when the
current_useris not found has been updated to include the HTTP status code 401. This is a good practice as it provides more context about the nature of the error (unauthorized).81-82: The error handling has been improved by specifying the HTTP status codes for different error scenarios. This makes it easier for clients to understand and handle different types of errors.
70-71: Special characters in
accountIdandList of ContentDocumentIdare now being escaped and the Salesforce query string is being URL encoded. This is a good security practice as it helps prevent injection attacks.73-74: The
CompositeRequestWrapperis now being used to make requests to Salesforce. This seems like a good abstraction that could potentially simplify the process of making these requests.79-80: The error handling for responses from Salesforce has been improved. The system now distinguishes between 400/404 and 500 errors, which can provide more information about what went wrong.
sequenceDiagrams/Common/UserAuthIntercepter.mermaid (4)
21-24: The error response code has been updated from a generic error to a specific 401 Unauthorized error, which is more appropriate when the cookie is null. This change improves the clarity of the error handling.
29-32: The error response code has been updated from a generic error to a specific 401 Unauthorized error, which is more appropriate when the cookie timestamp is expired. This change improves the clarity of the error handling.
38-41: The error response code has been updated from a generic error to a specific 500 Internal Server Error, which is more appropriate when there is an error from DynamoDB. This change improves the clarity of the error handling.
47-50: The error response code has been updated from a generic error to a specific 401 Unauthorized error, which is more appropriate when the CookieToken is invalid. This change improves the clarity of the error handling.
sequenceDiagrams/Accounts/GetAccounts.mermaid (7)
19-20: The error response now includes a specific HTTP status code (401) for when the current user is not found. This is an improvement as it provides more detailed information about the error.
55-56: The error handling has been improved by specifying HTTP status codes for different error scenarios. This makes it easier to understand the type of error that occurred.
31-32: The
getAccountListmethod of theGetAccountListServicenow takes an additional parameterGetAccountsDto: {q:String}. Ensure that all calls to this method throughout the codebase have been updated to match the new signature.34-35: The
getAccountListmethod of theGetAccountListFactorynow takes additional parametersviewKind: BASIC, offset: 0. Ensure that all calls to this method throughout the codebase have been updated to match the new signature.37-38: The
getAccountListmethod of the particular CRM service now takes additional parametersviewKind: BASIC, offset: 0. Ensure that all calls to this method throughout the codebase have been updated to match the new signature.39-42: These notes provide additional details on how the
getAccountListmethod of the particular CRM service works. They improve the readability and understanding of the code.64-65: The
GetAccountListResponseDtonow includes anAccountEntitywithidandnamefields. This is an improvement as it provides more detailed information in the response.sequenceDiagrams/User/GetCurrentUser.mermaid (1)
- 13-13: The change from a generic error response to a specific 401 Unauthorized error response is a good improvement. It provides more information about the nature of the error, which can be helpful for debugging and user feedback.
- api-->>ui: Error Response<br>current_user Not Found + api-->>ui: Return 401 Error Response<br>current_user Not FoundsequenceDiagrams/Suggestions/GetCrmActionSuggestions.mermaid (4)
- 16-20: The error message returned when
current_useris not found should ideally include an HTTP status code for better error handling on the client side. Consider modifying the error response to include a 401 Unauthorized status code.- api-->>ui: Error Response<br>current_user Not Found + api-->>ui: Error Response<br>Status: 401 Unauthorized<br>Message: current_user Not Found
- 49-61: The exception handling for parameter validation and OpenAI errors could be improved by providing more specific error messages. This would help in debugging and understanding the exact nature of the error.
- exceptionHandler-->>ui:Return 400 error response + exceptionHandler-->>ui:Return 400 error response<br>Message: Mandatory parameters missing or text length exceeded limit - wrapper->>exceptionHandler: Throws 500 exception - exceptionHandler-->>ui: Return 500 error response + wrapper->>exceptionHandler: Throws 500 exception<br>Message: Error from OpenAI API + exceptionHandler-->>ui: Return 500 error response<br>Message: Error from OpenAI API
- 44-45: The request to the OpenAI API seems to have empty
messagesandfunctionsparameters. Ensure these parameters are correctly populated before making the request.- Request: POST https://api.openai.com/v1/chat/completions <br><br>Params: <br> model: "gpt-3.5-turbo-0613" <br> messages: "" <br> functions: "" + Request: POST https://api.openai.com/v1/chat/completions <br><br>Params: <br> model: "gpt-3.5-turbo-0613" <br> messages: [appropriate_message] <br> functions: [appropriate_function]
- 67-68: Ensure that the date sanitization process handles all edge cases and formats the date correctly.
| # Salesforce Configuration Guide | ||
|
|
||
| ## Giving Permissions to Users | ||
|
|
||
| Configure Salesforce to give the necessary permissions to your Salesforce users for API access. API Only Users require specific configuration to access objects. | ||
|
|
||
| ## Steps: | ||
|
|
||
| 1. **Log in to Salesforce:** | ||
| - Log in to your Salesforce account using your credentials. | ||
|
|
||
| 2. **Navigate to Permission Sets:** | ||
| - Click on the settings icon near the profile picture in the top right corner. | ||
| - Select "Setup" from the dropdown menu. | ||
| - In the search box, type "Permission Sets" and select it. | ||
|
|
||
| 3. **Create a New Permission Set:** | ||
| - Click the "New" button. | ||
| - Fill in the required details: | ||
| - **Label:** Give your permissions set a unique name. | ||
| - **API Name:** This will be auto-filled based on the label. | ||
| - **Description:** You can fill in the description. | ||
| - Click on Save button | ||
|
|
||
| ### Step 4: Configure Object Settings | ||
|
|
||
| 1. **Navigate to the Permission Set Page** | ||
| - After creating your new permission set, go to the permission set details page. | ||
|
|
||
| 2. **Access Object Settings** | ||
| - Under the **Apps** section, click on **Object Settings**. | ||
| - You need to give permissions to Accounts, Contacts, Tasks, Users, and any other objects you want to access. | ||
|
|
||
| #### For Accounts | ||
| 1. Click on **Accounts** | ||
| 2. Click the **Edit** button. | ||
| - **Object Permissions:** Check the **Read** and **View All** checkboxes. | ||
| 3. Click the **Save** button. | ||
|
|
||
| #### For Contacts | ||
| 1. Click on **Contacts** | ||
| 2. Click the **Edit** button. | ||
| - **Object Permissions:** Check the **Read** and **View All** checkboxes. | ||
| 3. Click the **Save** button. | ||
|
|
||
| #### For Tasks | ||
| 1. Click on **Tasks** | ||
| 2. Click the **Edit** button. | ||
| - **Object Permissions:** Check the **Read** and **View All** checkboxes. | ||
| 3. Click the **Save** button. | ||
|
|
||
| 5. **Configure System Permissions:** | ||
| - Under System, of the newly created permission set page, click on System Permsissions | ||
| - Click on Edit button | ||
| - **Edit Tasks:** Check the checkbox | ||
| - **View All Data**: Check the checkbox | ||
| - Click on Save button | ||
|
|
||
| 5. **Assign permission to Users:** | ||
| - Click on the permission set you created | ||
| - Click on Manage Assignments button | ||
| - Click on Add Assignments button | ||
| - Select the users you want to give permissions to | ||
| - Click on Next button | ||
|
|
||
|
|
||
|
|
||
| # Add API only Users | ||
|
|
||
| You can add upto 5 API only users in your salesforce account. You can use these users to access the salesforce API. You can add these users by following the below steps: | ||
|
|
||
| 1. **Log in to Salesforce:** | ||
| Log in to your Salesforce account using your credentials. | ||
|
|
||
| 2. **Navigate to Users:** | ||
| - Click on the settings icon near the profile picture in the top right corner. | ||
| - Select "Setup" from the dropdown menu. | ||
| - In the search box, type "Users" and select it. | ||
|
|
||
| 3. **Create a New User:** | ||
| - Click the "New User" button. | ||
| - Fill in the required details: | ||
| - **First Name:** Give your user a first name. | ||
| - **Last Name:** Give your user a last name. | ||
| - **Email:** Give your user an email address. | ||
| - **Username:** Give your user a unique username. | ||
| - **Alias:** Give your user an alias. | ||
| - **Role:** Select a role for your user. You can leave it as None specified. | ||
| - **Profile:** Select a profile for your user. You can select Salesforce API Only System Integrations. | ||
| - **User License:** Select "Salesforce Integration". | ||
| - Click on Save button | ||
|
|
||
| 4. **Give Permission Set License Assignments** | ||
| - Click on the user you created | ||
| - Click on Permission Set License Assignments | ||
| - Click on Edit Assignments button | ||
| - Enable the "Salesforce API Integration" | ||
| - Click on Save button |
There was a problem hiding this comment.
The guide is well-written and provides clear instructions on how to configure Salesforce for API access. However, it would be beneficial to include screenshots or diagrams to visually aid users in following the steps. This can significantly improve the user experience and reduce potential confusion.
| sequenceDiagram | ||
| title Delete Account Note | ||
| participant ui as SalesSparrow Client | ||
| participant api as SalesSparrow API | ||
| participant exceptionHandler as Global Exception Handler | ||
| participant validator as Param Validator(Interceptor) | ||
| participant controller as AccountNote Controller | ||
| participant service as DeleteNote Service | ||
| participant factory as DeleteNote Factory | ||
| participant crm as Salesforce DeleteNote Service | ||
| participant CompositeRequestWrapper as CompositeRequest(Wrapper) | ||
| participant salesforce as Salesforce | ||
|
|
||
| ui->>api: Send request | ||
| note right of ui: Request: <br>DELETE {api_base_url}/v1/accounts/{account_id}/notes/{note_id}<br><br>path params: <br>account_id<br>note_id | ||
|
|
||
| note over api: Validate and fetch current user data from cookie<br>set currentUser attribute in request.<br><br>Refer this document for interceptor sequence diagram <br> './docs/sequenceDiagrams/Common/UserAuthIntercepter.mermaid' | ||
| break If currentUser not found | ||
| api-->>ui: Return 401 Error Response<br>currentUser Not Found | ||
| end | ||
|
|
||
| api->>validator: Validate path params | ||
|
|
||
| break If mandatory params not present in the body | ||
| validator->>exceptionHandler: Throws exeption | ||
| exceptionHandler-->>ui:Return 400 error response | ||
| end | ||
|
|
||
| validator->>controller: Send validated params<br>params: noteId, accountId | ||
|
|
||
| controller->>service: Call deleteNote method of DeleteNoteService<br> params: request, noteId, accountId | ||
| note over service: GetAttribute of currentUser from request<br>Which was set by interceptor | ||
|
|
||
| service->>factory: Call deleteNote method of DeleteNoteFactory<br>params: currentUser, noteId | ||
| note over factory: Based on currentUser identify CRM | ||
|
|
||
| factory->>crm: Call deleteNote method of particular CRM service<br>params: currentUser, noteId | ||
|
|
||
| note over crm: fetch salesforceUserId from request currentUser | ||
| break If salesforceUserId is not present in currentUser. | ||
| crm->>exceptionHandler: Throws exeption | ||
| exceptionHandler-->>ui:Return 400 error response | ||
| end | ||
| crm->>CompositeRequestWrapper: Send compositeBody to make request to salesforce<br>params: <br> List<requestType, url, referenceId>, salesforceUserId <br> | ||
|
|
||
| CompositeRequestWrapper->>salesforce: Make salesforce composite api call with commmon helper function<br><br>Refer this document for commmon helper function sequence diagram <br> './docs/sequenceDiagrams/Common/OAuthRequestHelper.mermaid' | ||
| note right of CompositeRequestWrapper: Request: POST {instance_url}/services/data/v58.0/composite <br><br>Params: <br> method: DELETE<br> url: "/services/data/v58.0/sobjects/ContentNote/${noteId}"<br>referenceId: "DeleteNote" | ||
|
|
||
| break | ||
| alt If 400 or 404 error from salesforce | ||
| salesforce-->>CompositeRequestWrapper: Return 400 error response: INVALID_NOTE_ID | ||
| CompositeRequestWrapper->>exceptionHandler: Throws exeption | ||
| exceptionHandler-->>ui: Return 400 error response | ||
| else | ||
| salesforce-->>CompositeRequestWrapper: Return 500 error response | ||
| CompositeRequestWrapper->>exceptionHandler: Throws exeption | ||
| exceptionHandler-->>ui: Return 500 error response | ||
| end | ||
| end | ||
|
|
||
| salesforce-->>CompositeRequestWrapper: Response | ||
| CompositeRequestWrapper-->>crm: Response | ||
|
|
||
| crm-->>factory: Response | ||
| factory-->>service: Response | ||
| service-->> controller: Response | ||
| controller-->>api: Response | ||
|
|
||
| api-->>ui: Success:204 | ||
| note right of ui: Response body: <br> {}<br><br>Response headers:<br> cookie |
There was a problem hiding this comment.
The sequence diagram is well-detailed and covers all the steps involved in deleting a note from an account. It includes error handling, validation checks, and participant interactions which are crucial for understanding the flow of the process. However, there's a minor typo in line 25 and 42 where "exeption" should be corrected to "exception".
- validator->>exceptionHandler: Throws exeption
+ validator->>exceptionHandler: Throws exception
- crm->>exceptionHandler: Throws exeption
+ crm->>exceptionHandler: Throws exception| sequenceDiagram | ||
| title Create Task API | ||
| participant ui as SalesSparrow Client | ||
| participant api as SalesSparrow API | ||
| participant exceptionHandler as Global Exception Handler | ||
| participant validator as Param Validator(Interceptor) | ||
| participant controller as Account Task Controller | ||
| participant service as CreateTask Service | ||
| participant factory as CreateTask Factory | ||
| participant crm as Salesforce CreateTask Service | ||
| participant CompositeRequestWrapper as CompositeRequest(Wrapper) | ||
| participant salesforce as Salesforce | ||
|
|
||
| ui->>api: Send request | ||
| note right of ui: Request: Request: <br>POST {api_base_url}/v1/accounts/{account_id}/tasks<br><br>Path params: <br>account_id <br><br> request body:<br>crm_organization_user_id <br>(CRM Organization userId for assigning task to User)<br>description (Description of Task)<br>due_date (Due Date of Task) | ||
|
|
||
| note over api: Validate and fetch current user data from cookie<br>set currentUser attribute in request.<br><br>Refer this document for interceptor sequence diagram <br> './docs/sequenceDiagrams/Common/UserAuthIntercepter.mermaid' | ||
| break If currentUser not found | ||
| api-->>ui: Error Response<br>currentUser Not Found | ||
| end | ||
|
|
||
| note over api: CreateTaskDto {<br>crmOrganizationUserId,<br>description,<br>dueDate<br>} | ||
|
|
||
| api->>validator: Validate path and body params | ||
|
|
||
| break | ||
| alt If mandatory params not present in the body | ||
| validator->>exceptionHandler: Throws exeption | ||
| exceptionHandler-->>ui:Return error response | ||
| else If description character length > 32000 | ||
| validator->>exceptionHandler: Throws exeption | ||
| exceptionHandler-->>ui:Return error response | ||
| else If due_date format is not valid date format | ||
| validator->>exceptionHandler: Throws exeption | ||
| exceptionHandler-->>ui:Return error response | ||
| end | ||
| end | ||
|
|
||
| validator->>controller: Send validated params<br>params: CreateTaskDto , accountId | ||
|
|
||
| controller->>service: Call createTask method of CreateTaskService<br> params: request, CreateTaskDto, accountId | ||
| note over service: GetAttribute of current_user from request<br>Which was set by interceptor | ||
|
|
||
| service->>factory: Call createTask method of CreateTaskFactory<br>params: currentUser, CreateTaskDto, accountId | ||
| note over factory: Based on currentUser identify CRM | ||
|
|
||
| factory->>crm: Call createTask method of particular CRM service<br>params: currentUser, CreateTaskDto, accountId | ||
|
|
||
| note over crm: fetch salesforceUserId from request currentUser | ||
| break If salesforceUserId is not present in currentUser. | ||
| crm->>exceptionHandler: Throws exeption | ||
| exceptionHandler-->>ui:Return error response | ||
| end | ||
| note over crm: Get subject as first 60 characters of the description. | ||
| crm->>CompositeRequestWrapper: Send compositeBody to make request to salesforce<br>params: <br> List<requestType, url, referenceId, body>, salesforceUserId <br> | ||
|
|
||
| CompositeRequestWrapper->>salesforce: Make salesforce composite api call with commmon helper function<br><br>Refer this document for commmon helper function sequence diagram <br> './docs/sequenceDiagrams/Common/OAuthRequestHelper.mermaid' | ||
| note right of CompositeRequestWrapper: Request: POST {instance_url}/services/data/v58.0/composite <br><br>Params: <br> requestType: POST<br> url: "/services/data/v58.0/sobjects/Task"<br>body: {<br>"Subject":@{subject},<br>"Description":@{CreateTaskDto.description},<br>"WhatId": @{accountId}, <br>"OwnerId": @{CreateTaskDto.crmOrganizationUserId},<br>"ActivityDate": @{CreateTaskDto.dueDate}<br>} <br>referenceId: "CreateTask"<br> | ||
|
|
||
| break If any error from salesforce | ||
| salesforce-->>CompositeRequestWrapper: Error | ||
| CompositeRequestWrapper->>exceptionHandler: Throws exeption | ||
| exceptionHandler-->>ui: Return error response | ||
| end | ||
|
|
||
| salesforce-->>CompositeRequestWrapper: Response | ||
| CompositeRequestWrapper-->>crm: Response | ||
|
|
||
| note over crm: Format Salesforce Response into CreateTaskFormatterDto<br>{taskId: String} | ||
|
|
||
| crm-->>factory: Response:<br>CreateTaskFormatterDto | ||
| factory-->>service: Response:<br>CreateTaskFormatterDto | ||
| service-->> controller: Response:<br>CreateTaskFormatterDto | ||
| controller-->>api: Response:<br>CreateTaskFormatterDto | ||
| note right of api: CreateTaskFormatterDto | ||
|
|
||
| api-->>ui: Success:201 | ||
| note right of ui: Response body: <br> {task_id:""}<br><br>Response headers:<br> cookie |
There was a problem hiding this comment.
The sequence diagram is well-detailed and covers all the steps involved in creating a task. It includes validation checks, error handling, and interactions between different components. However, there's a minor issue with the description length check.
else If description character length > 32000
else If description character length > 255Salesforce only allows a maximum of 255 characters for the Task Subject field, which you're setting as the first 60 characters of the description. So, it would be better to limit the description to 255 characters instead of 32000 to avoid any potential issues.
| sequenceDiagram | ||
| title Delete Account Task | ||
| participant ui as SalesSparrow Client | ||
| participant api as SalesSparrow API | ||
| participant exceptionHandler as Global Exception Handler | ||
| participant validator as Param Validator(Interceptor) | ||
| participant controller as AccountTask Controller | ||
| participant service as DeleteAccountTask Service | ||
| participant factory as DeleteAccountTask Factory | ||
| participant crm as Salesforce DeleteAccountTask Service | ||
| participant CompositeRequestWrapper as CompositeRequest(Wrapper) | ||
| participant salesforce as Salesforce | ||
|
|
||
| ui->>api: Send request | ||
| note right of ui: Request: <br>DELETE {api_base_url}/v1/accounts/{account_id}/tasks/{task_id}<br><br>path params: <br>account_id [mandatory]<br>task_id [mandatory] | ||
|
|
||
|
|
||
| note over api: Validate and fetch current user data from cookie<br>set currentUser attribute in request.<br><br>Refer this document for interceptor sequence diagram <br> './docs/sequenceDiagrams/Common/UserAuthIntercepter.mermaid' | ||
| break If currentUser not found | ||
| api-->>ui: Return 401 Error Response<br>currentUser Not Found | ||
| end | ||
|
|
||
| api->>validator: Validate path params | ||
|
|
||
| break | ||
| alt If mandatory params not present in the body | ||
| validator->>exceptionHandler: Throws exeption | ||
| exceptionHandler-->>ui:Return 400 error response | ||
| else If account_id or task_id is not valid | ||
| validator->>exceptionHandler: Throws exeption | ||
| exceptionHandler-->>ui:Return 400 error response | ||
| end | ||
| end | ||
|
|
||
| validator->>controller: Send validated params<br>params: taskId, accountId | ||
|
|
||
| controller->>service: Call deleteAccountTask method of DeleteAccountTaskService<br> params: request, taskId, accountId | ||
| note over service: GetAttribute of currentUser from request<br>Which was set by interceptor | ||
|
|
||
| service->>factory: Call deleteAccountTask method of DeleteAccountTaskFactory<br>params: currentUser, taskId | ||
| note over factory: Based on currentUser identify CRM | ||
|
|
||
| factory->>crm: Call deleteAccountTask method of particular CRM service<br>params: currentUser, taskId | ||
|
|
||
| note over crm: fetch salesforceUserId from request currentUser | ||
| break If salesforceUserId is not present in currentUser. | ||
| crm->>exceptionHandler: Throws exeption | ||
| exceptionHandler-->>ui:Return 400 error response | ||
| end | ||
| crm->>CompositeRequestWrapper: Send compositeBody to make request to salesforce<br>params: <br> List<requestType, url, referenceId>, salesforceUserId <br> | ||
|
|
||
| CompositeRequestWrapper->>salesforce: Make salesforce composite api call with commmon helper function<br><br>Refer this document for commmon helper function sequence diagram <br> './docs/sequenceDiagrams/Common/OAuthRequestHelper.mermaid' | ||
| note right of CompositeRequestWrapper: Request: POST {instance_url}/services/data/v58.0/composite <br><br>Params: <br> method: DELETE<br> url: "/services/data/v58.0/sobjects/ContentNote/${taskId}"<br>referenceId: "DeleteAccountTask" | ||
|
|
||
| break | ||
| alt If 400 or 404 error from salesforce | ||
| salesforce-->>CompositeRequestWrapper: Return 400 error response: INVALID_TASK_ID | ||
| CompositeRequestWrapper->>exceptionHandler: Throws exeption | ||
| exceptionHandler-->>ui: Return 400 error response | ||
| else | ||
| salesforce-->>CompositeRequestWrapper: Return 500 error response | ||
| CompositeRequestWrapper->>exceptionHandler: Throws exeption | ||
| exceptionHandler-->>ui: Return 500 error response | ||
| end | ||
| end | ||
|
|
||
| salesforce-->>CompositeRequestWrapper: Response | ||
| CompositeRequestWrapper-->>crm: Response | ||
|
|
||
| crm-->>factory: Response | ||
| factory-->>service: Response | ||
| service-->> controller: Response | ||
| controller-->>api: Response | ||
|
|
||
| api-->>ui: Success:204 | ||
| note right of ui: Response body: <br> {}<br><br>Response headers:<br> cookie |
There was a problem hiding this comment.
The sequence diagram is well-detailed and covers all the necessary steps in the process of deleting an account task. It includes error handling, validation checks, and participant interactions which are crucial for understanding the flow of the operation.
However, there's a minor inconsistency in the diagram. In line 57, Salesforce returns a 400 error response with the message INVALID_TASK_ID, but in the actual implementation, Salesforce doesn't return such specific error messages. Instead, it returns a generic error message like Bad Request or Not Found. Therefore, you should verify this part of the diagram to ensure its accuracy.
Also, consider adding more details about what happens when the deletion is successful. For example, does the system log the deletion? Does it trigger any other processes or updates? Adding these details can make the diagram even more comprehensive.
| sequenceDiagram | ||
| title Disconnect User | ||
| participant ui as SalesSparrow Client | ||
| participant api as SalesSparrow API | ||
| participant exceptionHandler as Global Exception Handler | ||
| participant controller as Auth Controller | ||
| participant service as DisconnectUser Service | ||
| participant factory as DisconnectUser Factory | ||
| participant crm as Salesforce DisconnectUser Service | ||
| participant tokensWrapper as Salesforce Tokens Wrapper | ||
| participant helper as Cookie Helper Lib | ||
| participant salesforce as Salesforce | ||
| participant dynamoDb as AWS DynamoDb | ||
| participant kms as AWS KMS | ||
|
|
||
|
|
||
| ui->>api: Send request | ||
| note right of ui: Request: <br>POST {api_base_url}/v1/auth/disconnect | ||
|
|
||
| note over api: Validate and fetch current user data from cookie<br>set current_user attribute in request.<br><br>Refer this document for interceptor sequence diagram <br> './docs/sequenceDiagrams/Common/UserAuthIntercepter.mermaid' | ||
|
|
||
| api->>controller: Controller specific logic execution starts | ||
|
|
||
| controller->>service: Call disconnect method of DisconnectUser service | ||
| service->>factory: Call disconnect method of DisconnectUser factory<br>params: current_user | ||
| note over factory: Based on current_user userKind identify CRM | ||
|
|
||
| factory->>crm: Call disconnect method of particular CRM service<br>params: current_user | ||
|
|
||
| crm ->> tokensWrapper: Call revokeRefreshToken method of Salesforce Tokens wrapper<br>params: externalUserId | ||
|
|
||
| tokensWrapper->>dynamoDb: Get refreshToken using externalUserId | ||
| break If any error from dynamoDb | ||
| dynamoDb -->> tokensWrapper: Error | ||
| tokensWrapper ->> exceptionHandler: Throws exception | ||
| exceptionHandler-->>ui: Return 500 error response | ||
| end | ||
|
|
||
| dynamoDb-->>tokensWrapper: Response: Encrypted refresh token | ||
|
|
||
| tokensWrapper ->> kms: Decrypt refresh token | ||
| break If any error decrypting refresh token | ||
| kms -->> tokensWrapper: Error | ||
| tokensWrapper ->> exceptionHandler: Throws exception | ||
| exceptionHandler-->>ui: Return 500 error response | ||
| end | ||
| kms -->> tokensWrapper: Response: Decrypted refresh token | ||
|
|
||
| note over tokensWrapper: Hit the salesforce revoke token API using http client. | ||
| tokensWrapper->>salesforce: Send request | ||
| note right of tokensWrapper: POST {salesforce_base_url}/services/oauth2/revoke<br><br>Body params: <br>token [mandatory] | ||
|
|
||
| break If any error from salesforce server | ||
| salesforce -->> tokensWrapper: Error | ||
| tokensWrapper ->> exceptionHandler: Throws exception | ||
| exceptionHandler-->>ui: Return 500 error response | ||
| end | ||
|
|
||
| salesforce -->> tokensWrapper: Response | ||
| tokensWrapper -->> crm: Response | ||
|
|
||
| note over service: Delete user's data from database | ||
|
|
||
| crm->>dynamoDb: Delete tokens data from salesforce_oauth_tokens table using externalUserId | ||
| break If any error from dynamoDb | ||
| dynamoDb -->> crm: Error | ||
| crm ->> exceptionHandler: Throws exception | ||
| exceptionHandler-->>ui: Return 500 error response | ||
| end | ||
|
|
||
| dynamoDb-->>crm: Response | ||
|
|
||
| crm->>dynamoDb: Remove users salesforce specific data from salesforce_users table using externalUserId and mark the status as deleted | ||
| break If any error from dynamoDb | ||
| dynamoDb -->> crm: Error | ||
| crm ->> exceptionHandler: Throws exception | ||
| exceptionHandler-->>ui: Return 500 error response | ||
| end | ||
|
|
||
| dynamoDb-->>crm: Response | ||
| crm-->>service: Response | ||
| service-->> controller: Response | ||
|
|
||
| controller->>helper: Call clearUserCookie method of cookie helper lib <br> param: headers | ||
| note over helper: Unset cookie value and change expiry to -1 | ||
| helper-->>controller: Response (headers) | ||
|
|
||
| note over controller: Add headers to response | ||
|
|
||
| controller-->>ui: 204 Success response |
There was a problem hiding this comment.
The sequence diagram is well-detailed and covers all the steps involved in the user disconnect process. It includes error handling at each step, which is a good practice. However, it would be beneficial to include more details about what kind of errors can occur at each step and how they are handled specifically. For example, what happens if the Salesforce server returns an error other than 500? Is there any retry mechanism or specific error message returned to the client?
| break If any other error from salesforce server | ||
| salesforce -->> salesforceWrapper: Error | ||
| salesforceWrapper ->> exceptionHandler: Throws exception | ||
| exceptionHandler-->>helper: Return error response | ||
| exceptionHandler-->>helper: Return 500 error response |
There was a problem hiding this comment.
The error handling has been improved by specifying the HTTP status code for the error response. This provides more information about the type of error that occurred.
- exceptionHandler-->>helper: Return error response
+ exceptionHandler-->>helper: Return 500 error response| break If any error encrypting Access token | ||
| kms -->> accessToken: Error | ||
| accessToken ->> exceptionHandler: Throws exception | ||
| exceptionHandler-->>helper: Return error response | ||
| exceptionHandler-->>helper: Return 500 error response |
There was a problem hiding this comment.
The error handling has been improved by specifying the HTTP status code for the error response. This provides more information about the type of error that occurred.
- exceptionHandler-->>helper: Return error response
+ exceptionHandler-->>helper: Return 500 error response| break If any error from dynamoDb | ||
| dynamoDb -->> accessToken: Error | ||
| accessToken ->> exceptionHandler: Throws exception | ||
| exceptionHandler-->>helper: Return error response | ||
| exceptionHandler-->>helper: Return 500 error response |
There was a problem hiding this comment.
The error handling has been improved by specifying the HTTP status code for the error response. This provides more information about the type of error that occurred.
- exceptionHandler-->>helper: Return error response
+ exceptionHandler-->>helper: Return 500 error response| break If any error from salesforce server | ||
| salesforce -->> requestHelper: Error | ||
| requestHelper ->> exceptionHandler: Throws exception | ||
| exceptionHandler-->>helper: Return error response | ||
| exceptionHandler-->>helper: Return 500 error response |
There was a problem hiding this comment.
The error handling has been improved by specifying the HTTP status code for the error response. This provides more information about the type of error that occurred.
- exceptionHandler-->>helper: Return error response
+ exceptionHandler-->>helper: Return 500 error response| break If any other error from salesforce server | ||
| salesforce -->> requestHelper: Error | ||
| requestHelper ->> exceptionHandler: Throws exception | ||
| exceptionHandler-->>helper: Return error response | ||
| exceptionHandler-->>helper: Return 500 error response |
There was a problem hiding this comment.
The error handling has been improved by specifying the HTTP status code for the error response. This provides more information about the type of error that occurred.
- exceptionHandler-->>helper: Return error response
+ exceptionHandler-->>helper: Return 500 error response
Added documentation for the following tickets:
Summary by CodeRabbit
Release Notes:
AccountNotes,AccountTasks, andSuggestions.